Business processes that require collaboration between different people are often supported by the completion and submission of forms. Many organisations have replaced, or are replacing, paper forms with electronic ones and there are many different ways to do so. However, one of the common approaches involves the use of spreadsheets as templates for forms.
In this case, the business process owner either creates, or supervises the creation, of a template spreadsheet document. A user participating in the business process will then make a copy of the template spreadsheet, filling values in to some of the cells that are blank in the template, and will submit the newly completed spreadsheet form, for example, by attaching it to an email.
Spreadsheets employ a declarative dataflow programming paradigm known as cell-oriented programming. This has been widely adopted by users who would not necessarily regard themselves as computer programmers, but who are sometimes carrying out programming activities through spreadsheets. Spreadsheets are now regarded as one of the most ubiquitous End User Programming (EUP) tools.
This paradigm allows the expression of a set of related logical constructs without having to focus on the particular flow of execution that the computer processor will carry out, as the execution engine is tasked with doing this in a manner transparent to the user. The spreadsheet concept also includes a two-dimensional (or even three-dimensional when extended to multiple sheets) visual layout of data and text that is intuitive and effective.
Forms that support business processes often benefit from being encoded in spreadsheets for a number of reasons, including: the layout of spreadsheets in rows and columns, allowing heterogeneous data to utilise a two-dimensional area effectively in a semi-structured fashion; calculations of values dependent on user-inputted data are often useful (for example, aggregate totals or conversion to other units); macros or spreadsheet extensions allow sourcing of relevant data from other computer systems.
A spreadsheet-based system is ‘Do-It-Yourself’ for the large number of end users that are comfortable with spreadsheet technology. Compared to an enterprise solution, this can make it faster, and, at least initially, less costly, to get an electronic system in place because it does not require the same level of specialist technical services to implement.
However, these advantages are sometimes counter-balanced by some disadvantages, particularly when considered from an enterprise perspective. The disadvantages include the lack of an ability to distinguish between user-entered data and the structure of the form (although this can be mitigated by protecting cells, there is no distinct categorization). The data is semi-structured at best. There is also a lack of an ability to deal with different record sets relating to the same form structure, including summarizing and querying across different record sets—since each form is in a separate file. There is also a lack of workflow tools to enable sequence control, allow for conditional logic, or track the status and approval of forms. The proliferation of files, including old or modified versions of template files, can be very difficult to manage.
It is these disadvantages, among others, that have led many organisations to invest in Business Process Management (BPM) software suites. These suites typically provide tools for designing form templates, together with a mechanism for defining dynamic behaviour. This may be in the form of an Application Programming Interface (API), or through the use of a flowchart-based workflow designer, for example, based on the Business Process Model and Notation (BPMN). They also typically store the data from submitted forms in a centralised database. Although these software suites effectively address many of the weaknesses of a spreadsheet-based system, they typically required highly trained technicians or professional computer programmers to implement.
The preceding discussion of the background to the invention is intended only to facilitate an understanding of the present invention. It should be appreciated that the discussion is not an acknowledgment or admission that any of the material referred to was part of the common general knowledge in the art as at the priority date of the application.